Group Project

Group Project Description

From course document

Group Number 6
EARS Project Assigned

We are just using a document based Waterfall methodology

Projects wil be implemented using C++/Java for Windows
Yikes, I use Linux so maybe I shouldn't do coding

Project Progress Presentation and Final Demonstration

There will be one project progress presentation and one final demonstration.

The progress presentation will be hold in XXX,
which worth $5$ of your project.

Towards the last week (probably during the last week, but possibly earlier),
each team will demonstrate the program they have developed to the "client(s)".

These should be geared towards "selling" the product.
These presentations not only are assessed,
but also the products on which they are based will be assessed

Official Project Description

Project 4 Employment Application Review System

EARS is an intranet-based Employment Application Review System for the Department of Math and Computer Science in Algoma University.

The system is designed so that department faculty members can review applicants and collaborate asynchronously in order to find the best applicant for a given job opening.

This system reduces the overhead of the process and lightens the workload for the search chairperson.

The scope of this project will be to provide a system that allows the CCMT to:

1. log-in EARS system
2. manage system users (add new accounts)
3. add a new faculty search (committee chair, members, position,
   search starting date and ending date, add new committee members)
4. List and review applications (view profile, post comments on applicants, change applicants’ statues, perform a faculty review, assign faculty review)
5. set account’s settings (email, name, title, password)

D2 Requirements and Specification - Resources

Review following links (in no specific order) for writing an effective SRS

Wikipedia ~ Software Requirements Specifications

Circle - Visual Paradigms ~ UML and Requirement Diagram

SRS Templates

exinfm.com - Training ~ SRS Template

gmu ~ SRS Template

dal ~ SRS Template

uccs ~ SRS Doc

SRS Articles

Your 2023 Guide to Writing a Software Requirements Specification – SRS Document by Andrew Burak CEO at Relevant
Blog Article

How to Write a Software Requirements Specification (SRS Document)
by Gerhard Krüger and Charles Lane
Blog Article

How to Create Requirements Spec. in Minutes?
Visual Paradigms ~ How to Create Software Requirements Spec with Doc Composer

Requirement Diagrams
Visual Paradigms

Software Requirement Specification

From Wikipedia ~ Software Requirements Specifications

It may include use cases

Example Structure Outline

1. Purpose
   1. Definitions
   2. Background
   3. System overview
   4. References
2. Overall description
   1. Product perspective
      1. System Interfaces
      2. User interfaces
      3. Hardware interfaces
      4. Software interfaces
      5. Communication Interfaces
      6. Memory constraints
   2. Design constraints
      1. Operations
      2. Site adaptation requirements
   3. Product functions
   4. User characteristics
   5. Constraints, assumptions and dependencies
3. Specific requirements
   1. External interface requirements
   2. Performance requirements
   3. Logical database requirement
   4. Software system attributes
      1. Reliability
      2. Availability
      3. Security
      4. Maintainability
      5. Portability
   5. Functional requirements
      1. Functional partitioning
      2. Functional description
      3. Control description
   6. Environment characteristics
      1. Hardware
      2. Peripherals
      3. Users
   7. Other

Requirement Smell

Following the idea of code smells, the notion of requirements smell has been proposed to describe issues in requirements specification where the requirement is not necessarily wrong but could be problematic

Examples of requirements smells are

• subjective language,
• ambiguous
• adverbs and adjectives,
• superlatives
• negative statements

Tasks

Lucas ~ Project Demo/Presentation
UML ~
Coding ~ Java

SRS Draft

Prepared by Lucas Cekan

Introduction

Product: Employment Application Review System

Purpose

This is a software requirements specification (SRS) document whose purpose is to define the requirements, purpose, limitation, features both functional and non-functional of this software product.

This document is prepared for a technical and non-technical audience alike for the purpose of laying out the features and requirements to start developing this software project.

Scope

This SRS is for the development of a Employment Application Review System (EARS)

The intended users of this system are the department faculty members at Algoma University at the Department of Math and Computer Science.

The software is meant to make the process of reviewing applications much easier and quicker. The costs in terms of overhead of effort, time and attention of reviewers should be reduced.

The goal of the system is to allow

1. The review of applicants
2. Collaboration between reviewers

Overall Description

This document will list the requirements and the features of this system. The features will divided into sub parts for example the login process and the faculty search listing the requirements for each sub-part.

This document will list a couple of intended use cases that should demonstrate how the software is intended to be used if the requirements are met.

The document will list the functional requirement, that is the basic requirements that must be met for this product to function and non-functional requirements, or the requirements that will add to the user experience but are not necessarily required for the product to function.

Software limitations will be listed based on the skills and experience of the developers assigned to this project. The use of Java and development software from the Java ecosystem such as JavaFX will be discussed.

Product Perspective

Here is a detailed description of the product and it's features

System's Categories

The system will be based on the following categories

1. System users
2. Applications
3. Faculty search feature

System Users

Users of this system must be able to

1. Log-in to the system using their email and password
2. Be able to change their account details
   • email
   • name
   • title
   • password
3. Add other users into the system
4. List and review applications
   • view a profile
   • post comments on applicants
   • change applicants' status
   • perform a faculty review
   • assign a faculty review

Applications

Each applications should be represented in the system by a profile, with comments from reviewers and a status representing

1. Waiting to be assigned a review
2. Waiting for the assigned reviewer to do the review
3. Review completed

The profile should display the

• comments from reviewers
• the applicant's statuses

Faculty Search Feature

The system should allow users to search the department's faculty members. Which should find the members and display their position starting and ending dates.

The current Committee chair should be displayed predominately and should be quickly found.

System Interfaces

The various views and the interfaces that a user would be confronted by are described here.

Login Screen

Users need to be able to login through a login screen when at the start of the applications.

Users should be able to go back to this view once if they choose to log off.

Users log in with their credentials that being their email and password.

Main User Interface

After the login process the users should be confronted with the main interface divided into sections.

1. A list of applications awaiting review

   • Applications that are requested and assigned for review for the specific user should be highlighted and at the top of the list
   • Followed by other applications that are need of a review
   • followed by applications that are completed and thus greyed out or similar by the user in question
   • followed by applications that were completed by other users

2. The header with information and icons for who is logged in and a attention icon that indicate that the user was assigned applications for review. The current committee chair should be displayed prominently.

3. A search bar for a faculty search, to find a faculty member quickly with a dropdown quickly displaying a starting date, ending date, position and a icon to add the member to the committee.

Profile Page

For each application there should be a profile displaying the applicant's typed application and list of their skills, proficiencies, education and so on. Followed by a comment thread below that users can discuss with each other about the application.

There should be action icons so that user can request a faculty review. The system should then record that this application has already been reviewed by the user.